Authorisation system in MorphIT

The server offers the connected ClassiX instances an interface via the method MorphITServerCommand to communicate directly with the MorphIT server. To decide whether a ClassiX instance may execute a command, the server assigns roles to the instances, which control the permissions of the ClassiX instances. By this mechanism certain ClassiX instances can be restricted in their rights. For example, a ClassiX instance can be started that is not allowed to terminate other ClassiX instances (shutdown_classix) or cannot start other instances (launch_dedicated_classix).

The commands RequestMorphITBinding and LaunchDedicatedClassiX are also implemented internally in the server as server commands and are subject to the same authorisation restrictions as the corresponding server commands.

The permissions are configured in the config.js in the permissions field. The preconfigured permissions allow all connected ClassiX instances to execute all commands.

Authorisations

Authorisations in MorphIT are identifiers hierarchically structured by points, which can be assigned(allow) or withdrawn(deny) in roles.

Examples:

server_command.launch_dedicated_classix
server_command.request_binding
server_command.request_binding.grant_role.user
server_command.shutdown_classix.role.local

Within the allow and deny lists there are the following abbreviations which simplify the definition of the authorisation lists:

Lists

In each authorisation, common parts can be "excluded" by means of curly brackets.

Example:

server_command.shutdown_classix
server_command.request_binding
server_command.launch_dedicated_classix

These permissions can also be written shorter as follows:

server_command.{shutdown_classix,request_binding,launch_dedicated_classix}

The lists are not restricted to one place. There may be several lists within one authorisation, which are then "multiplied out".

{a,b}.{d,e,f}

will be closed:

a.d
a.e
a.f
b.d
b.e
b.f

In addition, different nested identifiers are allowed within the lists.

a.{b,c.d}.e

will be closed:

a.b.e
a.c.d.e

The lists can also be nested.

a.{b,c.{d,e}}

will be closed:

a.b
a.c.d
a.c.e

The lists need not necessarily be aligned with the element boundaries of the identifier and may also contain empty elements, so that the following definition is syntactically correct (although difficult to read).

a{,.{c,d,e},bc}

Will be closed:

a
a.c
a.d
a.e
abc

Wildcards

Wildcards (.*) are also permitted at the end of the authorisations.

An a.* authorisation grants the following authorisations, among others

a
a.a
a.b
a.b.c

but not:

ab
abc

To assign a role the permission to execute all server commands, the following permission is sufficient: server_command.*

There is also the global wildcard:

*

Hereby all possible permissions are given (in allow) or denied(in deny).

Lists and wildcards can also be combined.

a.{b.*, c.d}

Will be closed:

a.b.*
a.c.d

Rolls

The permissions are grouped into roles and roles are grouped into categories. The category system is predefined, further categories can be freely defined. The roles must have unique names across all categories, as the category is not part of the role identifier.

Roles can be assigned to the ClassiX instances via certain server commands (example: request_binding).

Roles can be structured in the name analogous to permissions by a dot in the name (example: "user.admin"). This structuring can be used to overwrite all user roles in a role in inherits via "user.*".

A role is defined as an object with the following optional properties.

"deny" : [ "*" ]

Evaluation

A process can have 0-n rolls. A process without roles also has no authorisations. In MorphIT there are practically no processes without roles, because the server assigns at least 2 system roles to each process.

To check whether a process with n roles has a specific authorisation, all roles that have been overwritten by overwrites are removed from these roles. Then the roles inherited via inherits are added to the set of roles from the remaining roles and then the allow lists of all roles are combined to a total white list and the deny lists of all roles are combined to a total black list. In order for a process to have a specific permission, it must appear in the overall whitelist and must not appear in the overall blacklist.

Parameterised roles

Parameterised roles offer the possibility to dynamically generate new roles from a template. A parameterised role has a regular role identifier. Individual role segments (separated by a dot) can be replaced by role parameters (identifier with a preceding @). If a role contains at least one role parameter, it is a parameterised role.

Examples:

user.@id
location.@state.@city.@street
user.@id.admin

The @-parameters can then be referred to in the role definition in allow, deny, overwrites and inherits. Additionally to the defined parameters there is the always defined parameter @self, which contains the full name of the role.

Example definition:

"user.@id": {
  "allow":["server_command.shutdown_classix{,.role.@self}"]  
},
"location.@state.@city.@street": {
  "allow":["@state", "@city", "@street"]
},
"user.@id.admin": {
  "inherits":"user.@id",
  "allow":["server_command.shutdown_classix.role.*"]
}

For example, if the role client.12345 is assigned to a started ClassiX instance in the server command request_binding, then this instance can only terminate itself and other ClassiX instances, which have exactly the same role(@self is evaluated to client.12345 in this case). An instance with the role client.32546 could not terminate it. In this way the ClassiX instances can be grouped and isolated from each other, if they should not influence each other.

Due to the hierarchical structure of the roles, a role with the authorisation: server_command.shutdown_classix.role.client.* can terminate all instances that have the parameterised client role, regardless of the parameters.

System roles

System roles are all roles within permissions.roles.system. These are automatically assigned by the MorphIT server based on the connection parameters and cannot be influenced by the ClassiX instances.

The following system roles are available: